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less,  refined  extensions  of  doctrinal  concepts  which  were  in 
use  for  three  centuries .  These  functional  doctrines  have 
survived  until  today  because  they  have  been  in  general  success 
ful  and  effective.  Today  however  we  are  entering  a  new  era. 
New  effective  weapon  systems,  often  with  embedded  computers, 
introduce  the  impersonal  mass  destruction  of  the  enemy  by 
long-range  indirect  and  direct  fire,  requiring  complete, 
precise  and  especially  timely  information  on  the  battlefield 
status.  Thus  the  traditional  staff  function  will  not  be 
effective  enough  in  the  modern  warfare  unless  automated  infor¬ 
mation  processing  means  are  studied,  designed,  developed  and 
used. 

This  thesis  analyzes  the  Large  Army  Formation  (LAF)  as  an 
information  system,  identifies  and  defines  the  functional 
automation  of  the  staff  and  provides  a  preliminary  and  basic 
source  study  for  future  detailed  investigation  on  the  feasi¬ 
bility  and  utility  of  the  automation  in  the  Greek  Large  Army 
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I .  THE  LAF  AS  AN  INFORMATION  SYSTEM  [1,2,3] 


A.  MISSION,  GOAL,  AND  OBJECTIVES  OF  THE  LAF 

1 .  Definition  of  the  LAF 

The  LAF  is  an  army  unit  that  comprises  a  balanced 

force  of  essential  ground  arms  and  services  so  organized  and 
equipped  as  to  make  it  tactically  and  administratively  self- 
contained.  That  is,  it  can  conduct  by  its  own  means  ground 
operations  of  general  importance.  It  can  strike  or  pene¬ 
trate  effectively,  maneuver  readily  over  any  type  of  terrain 
and  absorb  reinforcing  units  easily. 

2 .  Mission  of  the  LAF 

The  mission  of  the  LAF  can  be  any  or  all  of  the 
following : 

a.  To  seize  and  secure  an  area  and  to  deny  its  use  to 
the  enemy. 

b.  To  dominate  key  or  vital  land  areas  and  their  popu¬ 
lation  and  resources. 

c.  To  destroy  or  capture  enemy  military  forces. 

3 .  Goal  of  the  LAF 

The  goal  of  the  LAF  is  the  successful  fulfillment 
of  its  specified  mission. 


The  objectives  of  the  LAF  are  concrete  and  specific 


accomplishments  necessary  to  the  achievement  of  its  goal. 

The  main  objectives  of  the  LAF  are: 

a.  With  respect  to  Personnel 

Good  Health 

High  degree  of  Training  and  Education 

Discipline  and  High  Morale 

2 

b.  With  respect  to  Equipment 

High  Performance 

Good  Maintenance 

c.  With  respect  to  Functionality 

Precision 

Actions  in  Time 

Effectiveness 

Low  Cost 

5 .  Dependency  and  Relations  Among  Mission,  Objectives 
and  Goal 

The  mission  of  the  LAF  is  expressed  by  the  military 
manuals  in  a  general  manner  and  needs  to  be  specified  ex¬ 
plicitly  either  by  the  orders  of  the  LAF's  superior  echelon 
or  by  the  LAF's  command.  This  specification  is  an  aftermath 
of  considerations  of  several  factors  like  the  strength  and 
the  operational  ability  of  the  LAF,  the  strength  and  behavior 


"''These  must  not  be  confused  with  the  terrain  objectives 
on  the  battlefield. 

2 

Weapons,  Munition,  Ammunition,  Vehicles,  Facilities,  Supplies 


of  the  enemy,  the  land  morphology,  the  weather  conditions. 

As  these  factors  are  related  to  time,  they  confound  the 
tactical  situation.  The  mission's  specification  is  an  adapta¬ 
tion  over  time.  The  estimation  of  the  situation  is  a  con¬ 
tinuing  process  and  changed  conditions  may  call  for  a  new 
decision  at  any  time  that  could  modify  the  mission's 
specification . 

The  objectives  of  the  LAF  are  dependent  on  the  mission's 
adaptation  in  a  considerable  way.  For  example,  military 
operations  conducted  under  conditions  of  extreme  cold  and 
deep  snow  require  special  equipment  and  training  for  the 
LAF  designated  to  conduct  such  operations.  The  objectives 
are  also  strongly  related  to  each  other.  For  example,  a 
high  degree  of  personnel  training  results  in  good  maintenance 
and  performance  of  the  equipment.  The  high  performance  of 
the  equipment  facilitates  the  personnel  training.  A  high 
degree  of  personnel  training  and  high  performance  of  the 
equipment  leads  to  an  effective  functioning  of  the  system. 

The  achievement  of  the  LAF's  goal  is  exclusively 
dependent  on  the  accomplishment  of  its  objectives.  Moreover, 
the  achievement  or  failure  of  the  goal  can  cause  an  adapta¬ 
tion  of  the  mission.  For  example,  after  a  successful  attack 
when  the  enemy  is  no  longer  able  to  maintain  his  position, 
then  the  mission  of  the  LAF  must  enter  a  new  phase;  a  pursuit 
must  be  launched. 

Figure  1.1  shows  the  dependency  and  the  relations 
among  mission,  objectives  and  goal  of  the  LAF. 


A  system  is  a  combination  of  diverse  but  interacting 
elements  integrated  to  achieve  its  overall  purpose.  The 
elements  may  be  devices  and/or  human  beings  concerned  with 
processing  materials,  information  and  energy.  A  feedback 
loop  for  returning  part  of  the  output  to  the  input  in  order 
to  improve  performance  is  an  important  functional  component 
in  many  systems.  The  concept  of  feedback  is  not  new;  it  is 
inherent  in  many  biological  systems,  and  it  is  found  in  well- 
established  social  systems.  However  the  formulation  of  the 
principles  of  feedback  is  a  recent  achievement,  credited  to 
H.S.  Black  in  his  studies  in  1934,  and  exploitation  of  this 
new  understanding  has  come  in  just  the  last  few  years. 

The  LAF  is  a  feedback  or  a  closed  loop  system.  That 
is,  it  provides  command  and  staff  with  a  comparison  of  both 
actual  and  desired  output.  The  input  of  the  LAF  is  its  speci 
fied  mission,  the  desired  output  is  either  the  accomplishment 
of  its  objectives  in  the  time  of  peace  or  the  achievement  of 
its  goal  in  the  time  of  war.  This  comparison  can  trigger 
the  LAF 1 s  command  and  staff  to  take  action  in  order  to  bring 
desired  and  actual  output  into  correspondence.  So  the  compar 
son  of  desired  and  actual  output  requires  an  explicitly  docu¬ 
mented  specification  of  the  mission  and  a  measurement  of  the 
actual  output.  The  measurement  of  the  actual  output  comes 
from  either  evaluations  with  respect  to  the  LAF's  objectives 
or  the  estimation  of  the  situation  with  respect  to  the  LAF's 


Each  closed  loop  or  feedback  system  is  effective  if 
it  can  respond  fast  for  the  necessary  control  action.  Other¬ 
wise  the  time  lapse  maybe  so  great  that  belated  control  action 
can  make  the  situation  worse  [Ref.  1,  p.  61].  Such  systems 
are  said  to  be  unstable.  In  an  unstable  system,  a  random 
disturbing  input  may  give  rise  to  decoordination  of  the 
system.  The  LAF  is  an  unstable  system,  thus  a  sudden  unfore¬ 
seen  enemy  action,  the  lack  of  fast  control  response  or 
misestimation  of  the  situation  can  often  be  a  catastrophe 
for  the  LAF.  By  nature,  an  unstable  system  is  difficult  to 
control.  On  the  other  hand,  the  requirements  for  certain 
results  of  a  military  action  impose  difficult  planning  prob¬ 
lems  for  the  staff,  who  are  the  control  engineers  of  the  LAF. 
The  use  of  automated  tools  will  be,  if  not  a  panacea,  at 
least  a  means  to  maximize  the  control  abilities  of  the  staff 
and  to  minimize  the  unforeseen  situations. 

Figure  1.2  presents  the  LAF  as  a  closed  loop  system. 

B.  THE  LAF:  A  SYSTEM  OF  SYSTEMS 

The  LAF  is  a  system  which  is  composed  of  two  smaller 
entities  which  are  also  systems.  These  systems  are  the 
LAF's  staff,  a  planning  and  control  functional  system  and  the 
totality  of  the  LAF  subordinate  echelons  which  constitute 
an  executive  system.  These  systems  are  also  divided  into 
subsystems.  This  work  focuses  on  the  staff  since  the  sub¬ 
systems  of  the  executive  system  (small  groups  and  units)  are 
beyond  its  scope. 


The  Staff  and  Its  Subsystems 
The  mission  of  the  staff  is: 

1.  To  conduct  methodical  analysis  of  any  tactical  or 
procedural  problem  in  the  activities  of  the  LAF,  to 
elaborate  fast,  precise  and  satisfactory  solutions 
and  to  present  these  solutions  to  the  LAF ' s  Commander 
General  Officer  in  order  to  reach  a  decision. 

2.  To  interpret  with  accuracy  the  decisions  of  the  General 
into  orders  and  to  issue  these  orders  at  the  proper 
time . 

3.  To  always  be  informed  in  time  on  the  situation  and 
to  be  sure  that  all  the  relevant  factors  have  been 
considered. 

4.  To  be  able  to  quickly  control  and  coordinate  the 
operations . 

5.  To  minimize  the  probability  of  errors. 

6.  To  relieve,  as  much  as  possible,  the  Commander  General 
from  the  supervision  of  activities  that  are  not  vitally 
important . 

The  basic  subsystems  of  the  staff  are  those  of  personnel, 
intelligence,  operations  and  logistics.  These  subsystems 
have  a  number  of  significant  functions  that  should  be 
considered . 

1.  Personnel 


Personnel  functions  are  intended  to  keep  the  LAF  in¬ 
formed  on  personnel  strength,  the  administrative  situation. 


the  current  battle  personnel  needs  and  changes  in  priority 
These  functions  include: 


a.  Developing  Estimates 

b.  Maintaining  LAF ' s  Strength  Status 

c.  Supervision  of  Personnel  Management. 

2 .  Intelligence 

Intelligence  functions  are  intended  to  provide  the 
LAF  with  intelligence  information  on  which  to  base  current 
tactical  decisions.  The  functions  performed  include: 

a.  Planning  of  Information  Collection 

b.  Information  Collection  Management 

c.  Information  Analysis  and  verification 

d.  Dissemination  of  Analysis  Products 

e.  Coordination  of  Counterintelligence 

f.  Coordination  of  Informants 

g.  Planning  and  Coordination  of  Reconnaissance. 

3.  Operations  and  Training 
Operations  and  training  functions  are  intended  to 

support  the  LAF  by  having  highly  trained  personnel  and  by 
controlling  immediate  combat  operations  and  sustaining  battle 
The  functions  performed  include: 

a.  Preparation  of  Training  and  Education  Plans 

b.  Coordination  of  Training 

c.  Coordination  and  Processing  Evaluations 

d.  Preparation  of  Operation  Plans 

e.  Coordination  of  Tactical  Troop  Movements 


f.  Coordination  of  Nuclear  and  Chemical  Weapons 

g.  Maintaining  an  Operation's  Estimate 

h.  Planning  and  Processing  Air  Support  Requests 

i.  Supervision  of  Electronic  Warfare. 

4 .  Logistics 

Logistics  functions  are  intended  to  coordinate  the 
logistics  requirements  of  the  LAF  with  the  tactical  aspects 
of  the  LAF's  activities.  The  functions  performed  include: 

a.  Planning  Supply,  Services,  and  Maintenance 

b.  Monitoring  the  Logistic  Situation  and  Capability 

c.  Monitoring  the  Medical  Activity 

d.  Monitoring  the  Airlifting  of  the  LAF. 

A  well-working  staff  speeds  up  the  elaboration  of 
the  information  and  transforms  it  to  useful  material  for 
decision  making.  The  introduction  of  automated  information 
processing  means  will  make  the  staff  more  productive  by  mini¬ 
mizing  the  delays  in  the  preparation  and  distribution  of  the 
estimations,  plans,  and  directions. 

C.  THE  LAF'S  INFORMATION  NEEDS 

The  information  that  a  LAF  must  elaborate  to  meet  its 
operational  needs  is  generated  by  its  internal  reporting 
structure  and  by  its  external  environment  as  well. 

The  information  generated  is  not  simply  useful  to  any 


army  unit  but  is  of  vital  importance.  The  whole  mission's 
adaptation  is  based  on  the  information  generated  in  the  LAF's 


internal  and  external  environment.  Good  exploitation  of 
information  leads  to  better  estimations  of  the  situation 
which  leads  to  better  decision  making.  Lack  of  information 
or  misinterpretation  of  the  information  may  be  fatal,  not 
only  for  the  success  of  a  tactical  action  on  the  battlefield 
but  also  for  the  existence  of  the  unit  itself.  We  could  say 
that  no  tactical  action  is  possible  without  inf ormation--it 
is  the  oxygen  for  every  army  organism  on  the  battlefield. 
Because  of  this  "starvation"  for  information,  there  is  the 
intelligence  subsystem  of  the  staff  which  has  as  its  primary 
role  the  coverage  of  the  needs  of  the  LAF  for  exploitable 
information. 

Fig.  1.4  shows  the  LAF ' s  main  information  generators. 

At  each  management  level,  the  specific  requirements  for 
information  vary.  The  different  information  uses  and  re¬ 
quirements  at  each  command  &  management  level  are  summarized 
in  Fig.  1.5. 


Figure  1.1:  LAF ' s  Missicn-Ob jective-Goal  Networ 
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Figure  1.3:  LAF  is  a  System  of  Systems. 
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MODELING  A  STAFF  ASSISTANT  COMPUTER  SYSTEM  (SACS)  [4,5] 


A.  AUTOMATION  NEEDS — EXPECTATIONS 

Before  making  the  configuration  of  any  computer  system  for 
assisting  the  staff  functions,  the  needs  of  this  system  should 
be  identified. 

Although  there  are  problems  inherent  in  specifying  the 
requirements  to  be  met  by  something  that  does  not  yet  exist 
(similar  to  convincing  a  farmer  of  his  need  for  a  tractor 
he  has  never  seen) ,  a  SACS  is  expected  to  meet  the  following 
requirements : 

1.  Exchange  data  with  other  tactical  data  systems 

2.  Build  and  maintain  data  bases 

3.  Perform  tactical  analysis  functions  to  support  control 
actions  and  decision  making 

4 .  Provide  displays  and  graphics  to  support  tactical 
operations  and  daily  procedures 

5.  Interface  with  detection  systems 

6.  Provide  functions  to  support  tactical  war  games  for 
the  LAF's  senior  personnel  training. 

Figure  2.1  presents  a  matrix  which  lists  the  automation 
needs--expectations  for  the  SACS,  with  respect  to  staff 
functional  subsystems. 


B.  PROBLEMS 


The  expansion  of  automated  assistance  for  staff  activi¬ 
ties  is  inevitably  accompanied  by  two  major  problems: 

1.  The  machine  problem--that  of  making  computing  power 
available  to  staff  personnel 

2.  The  human  problem--that  of  motivating  staff  personnel 
to  utilize  computers. 

Attempting  a  solution  to  the  first  problem,  a  SACS  model 
will  be  presented  which,  if  completed  and  finally  implemented, 
could  insure  the  availability  of  computer  resources  throughout 
the  staff  environment.  The  solution  to  the  problem  of  user 
motivation  for  exploitation  of  automated  assistance  will  be 
embodied  in  a  proposed  user  communications  pattern. 

C.  SACS  DEFINITION 

SACS  must  be  a  secure,  militarized,  automatic  system 
composed  of  the  automatic  data  processing  elements: 

1 .  Hardware 

2.  Firmware 

3.  Software 

4.  Communications  Network, 

required  for  performing  the  receiving,  filtering,  processing, 
storing  and  correlating  of  input  data  and  also  for  printing 
and  disseminating  the  information  product.  This  is  to  sup¬ 
port  the  staff  in  increasing  its  productivity  and  the  quality 
of  its  work  and  to  support  commanders  in  their  decision  making 


D.  SACS  HARDWARE  COMPONENTS  DESCRIPTION 


SACS  must  have  the  following  hardware  components  in  order 
to  accomplish  its  intended  task. 

1 .  LAF  Main  Computer  (LMC) 

The  LMC  must  provide  the  major  computing  capability 
in  the  LAF.  It  must  be  able: 

a.  To  maintain  large  data  bases 

b.  To  perform  numerical  calculations 

c.  To  perform  filtering 

d.  To  perform  correlation  of  information 

e.  To  respond  to  queries 

f.  To  support  other  required  processes  and  algorithms 

g.  To  accept  and  transmit  messages  from  and  to  SACS  users 
and  interoperating  systems 

h.  To  perform  color  graphic  compositions. 

The  LMC  can  be  a  supermini  system  in  order  to  cover 
the  above  listed  requirements,  in  a  satisfactory  way  in  terms 
of  accuracy  and  fast  response. 

2 .  The  Peripheral  Control  Unit 

The  PCU  must  be  a  small  scale  computer  capable  of 
storing  messages  and  color ^  graphics  data,  prompting  for  mes¬ 
sage  and  color  graphic  composition  and  enabling  the  several 
consoles  to  interact  with  the  LMC  and  to  accept  messages  and 
pictures  from  the  detection  systems. 
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The  color  is  considered  necessary  to  enable  a  vivid 
illustration  of  maps,  friendly  and  foe  force  dispositions,  et< 


.  The  Tactical  Analysis  Console  (TAC) 


The  TAC  must  provide  the  user  with  the  capability  to 
have  color  graphics  and  alphanumeric  input  and  output  with 
or  without  an  illuminated  color  map  background  and  color  hard¬ 
copy  output.  TACs  must  be  connected  to  PCUs  and  must  have  a 
color  display,  a  keyboard,  a  "mouse,"  a  printer,  and  a  plotter 
The  TAC  must  be  capable  of  input  and  output  of  formatted  or 
free  text  and  of  providing  the  user  with  the  capability  to 
review,  store,  manipulate  and  disseminate  data  on  request  and 
automatically . 

4.  The  Large  Display  Panel  (LCP) 


The  LDP  must  be  a  computer  driven  large  screen  which 
will  permit  the  integration  of  tactical  command  and  control 
data  on  a  universal  traverse  mercator  map  background  and  must 
facilitate  user  interaction  with  the  data  base.  It  must  pro¬ 
vide  the  user  the  capability  to  create  new  color  displays 
interactively,  display  information  from  the  data  base  through 
direct  communication  with  the  LMC  or  indirectly  through  a 
connection  with  a  PCU,  update  the  data  base,  and  store  and 
retrieve  displays.  The  LDP  must  have  sufficient  memory  for 
storing  the  display  symbology  used  in  conjunction  with  standard 
military  maps. 

5.  The  Geometry  Engine  (GE)  Style  Subsystem  (GESS) 
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The  GESS  must  provide  realistic  visual  simulation  for 
real-time  manipulation  of  geometry  and  other  information  taken 


See  "The  Geometry  Engine,  a  VLSI  Geometry  System  for 
Graphics,"  by  J.H.  Clark,  Computer  Graphics,  July  1982. 
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by  detection  systems.  The  GESS  must  output  smooth  continuous 
curves  of  2D  and  3D  transformations  and  sharp  readable  textual 
descriptions  of  the  behavior  of  the  corresponding  displayed 
object  pictures. 

6 .  The  Detection  Mapping  Modulator  {DMM) 

The  DMM  must  interpret  the  signals  which  are  received 
by  the  detection  systems  and  which  are  interpreted  locally 
into  radar  screen  videos,  into  target  geometric  elements, 
and  routed  to  the  SPCU. 

7 .  The  Special  Purpose  Control  Unit  (SPCU) 

The  SPCU  must  have  the  capability  to  control  the 
outputs  of  the  DMM,  to  compose  the  target  information  collected 
by  adjacent  detection  systems  with  overlapped  observation 
areas  into  integrated  target  information  of  larger  areas 
(e.g.,  the  combat  zone  of  the  LAF) ,  and  to  feed  appropriately 
the  GESS  with  the  geometric  elements  of  the  corresponding 
targets . 

8 .  The  Common  Tactical  Console  (CTC) 

The  CTC  must  be  used  for  the  display  of,  and  interaction 
with  computer  stored  data.  It  must  be  a  small,  transportable 
device  capable  of  sending  and  receiving  alphanumer ics  and 
unsophisticated  graphics  through  the  PCU.  The  CTC  must  be 
equipped  with  one  color  plasma  display,  a  keyboard  and  a 
printer.  For  alphanumeric  data,  the  CTC  must  provide  the 
user  the  capability  to  display  prompt  message  composition, 
edit  messages,  and  input  and  output  messages  in  formatted 


or  free  text.  For  simple  graphics  data,  the  CTC  must  provide 
the  user  with  the  capability  to  create  new  displays  inter¬ 
actively,  display  information  from  the  database  indirectly 
through  connection  with  a  PCU,  update  the  database  and  store 
and  retrieve  displays  of  military  symbology. 

E.  SACS  HARDWARE  TOPOLOGY  AND  WORKSTATIONS 


SACS  hardware  components  must  be  located  at  the  LAF 
tactical  command  post  and  at  some  of  its  subordinate  echelon 
commands . 
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5.  The  Logistics  Subsystem 


a.  One  PCU 

b .  One  TAC 

c.  One  CTC 

Figures  2.4  and  2.5  show  the  workstation  organizations 
of  the  several  subsystems.  Some  CTCs  should  also  be  given  to 
the  subordinate  commands  of  the  LAF  if  the  LAF  happens  to  be 
an  independent  brigade.  If  the  LAF  is  a  larger  unit  then  it 
will  have  subordinate  LAFs  having  their  own  SACSs. 

F.  SACS  SOFTWARE  COMPONENTS  DESCRIPTION 

1 .  Enemy  Situation  Applications  Software 
a.  Enemy  Situation  Data  (ESD) 

The  ESD  file  must  contain  data  and  intelligence 
concerning  enemy  units,  equipment,  personnel,  installations 
and  activities.  The  application  program  associated  with  this 
file  should  provide  for  collection,  storage,  dissemination 
and  selective  retrieval  of  current  enemy  information.  The 
major  components  of  ESD  file  entries  must  be:  intelligence 
subject;  combat  activity;  unit  element,  equipment  and  location; 
morale;  losses;  weapon  system  activities;  target  identification 
and  target  characteristics.  Related  to  each  ESD  message  should 
be  a  list  of  users  interested  and  authorized  for  the  use  of 
data  contained  in  the  message.  Users  authorized  interest 
may  be  indicated  in  the  following  ways:  (1)  Users  are  speci¬ 
fied  as  interested  with  the  submission  of  the  message;  (2)  An 
incoming  ESD  message  satisfies  the  user  criteria  for  a  standing 


request  for  information;  (3)  A  reviewer  of  the  incoming  mes¬ 
sage  determines  those  interested  in  the  message.  Authorized 
users  of  enemy  information  may  indicate  their  interest  in 
messages  as  a  means  of  retrieving  data  from  the  file.  All 
system  users,  collection  agents  and  sources  may  and  should 
provide  data  for  this  application.  The  ECD  in  few  words 
should  provide  the  basic  intelligence  reporting  mechanism  for 
system  users  and  should  form  the  basis  for  developing  enemy 
order  of  battle,  targeting  and  other  processed  intelligence. 

b.  Enemy  Order  of  Battle  (EOB) 

The  EOB  file  should  contain  processed  and  evalu¬ 
ated  information  about  enemy  units  and  their  structure.  The 
corresponding  application  program  should  provide  the  user  with 
the  capability  to  enter,  maintain  and  process  enemy  force 
information  and  to  identify  those  elements  of  the  enemy  not 
yet  located  or  whose  location  data  is  suspect.  The  major  EOB 
file  entries  should  be:  unit  identification,  location, 
subordination,  status,  combat  activity,  and  combat  effectiveness. 

c.  Filter 

Filtering  must  be  a  process  which  should  provide 
the  capability  for  checking  incoming  ESD  data  for  redundancy 
with  the  current  data  base. 

d.  Correlation 

Correlation  must  be  a  process  which  should  provide 
the  capability  for  relating  new  ESD  data  to  those  existing  in 


the  database. 


Friendly  Situation  Application  Software 


a.  Unit  Operations  Report  (UOR) 

The  UOR  will  be  a  process  which  must  permit  auto¬ 
matic  record  communication  between  the  LAF  and  its  subordinate 
echelons  with  respect  to  enemy  activity,  weather,  terrain 
and  tactical  activity.  Provision  is  to  be  made  for  entry, 
dissemination,  storage  and  selected  retrieval  of  UOR  messages. 

b.  Task  Organization  (TO) 

The  TO  file  should  contain  information  on  the 
assignment  and  attachment  of  friendly  forces.  The  corres¬ 
ponding  application  program  should  provide  the  Operations  Sub¬ 
system  personnel  the  capability  to  enter,  retrieve,  and  modify 
proposed  changes  to  the  task  organization.  This  application 
will  also  store  task  organization  changes  planned  for  future 
use  and  change  the  TO  file  on  order.  The  major  TO  entries 
should  be:  Unit  designation,  type,  subordination . 

c.  Tactical  Dispositions  (TD) 

The  TD  file  should  contain  geographic  data  related 
to  combat  support  elements,  service  support  locations,  and 
certain  tactical  control  measures.  The  major  entries  should 
be  unit  identification,  location,  type  of  location  like  com¬ 
mand  post,  center  of  mass,  objectives,  blocking  and  delay 
ground  points,  boundaries,  coordination  lines,  assembly  areas. 


3 .  Applications  Support  Software 

a.  Battlefield  Information  Reports  (BIR) 

The  BIR  should  contain  the  major  subordinate  com¬ 
bat  maneuver  elements  and  other  designated  units.  The  con¬ 
tents  should  include  location,  activity,  intensity  of  conflict 
and  the  commander's  perception  of  the  situation.  This  report 
should  be  transmitted  at  specified  intervals  to  LAF  tactical 
command  post. 

b.  Management  of  Intelligence  Collection  (MIC) 

The  MIC  should  be  a  function  which  will  provide 
intelligence  personnel  with  a  set  of  files  and  processes  to 
assist  the  collection  management  procedures.  The  following 
files  should  comprise  the  MIC:  (1)  Intelligence  Collection 

Agent  ( ICA)  file  which  will  identify  each  collection  agency 
and  its  available  collection  means;  (2)  Intelligence  Collection 
Characteristics  (ICC)  file  which  will  contain  the  range  and 
degree  of  coverage  for  each  collection  means;  (3)  Intelli¬ 
gence  Collection  Requirements  (ICR)  file  which  will  contain 
data  specifying  the  information  needed  and  reporting  criteria; 
(4)  Intelligence  Collection  Tasking  (ICT)  file  which  will 
identify  the  specific  tasking  requirements  assigned  to  each 
agency . 

c.  Named  Area  of  Interest  (NAI) 

The  NAI  should  be  a  process  which  will  provide 
users  the  capability  of  assigning  a  name  to  a  geographical 
point,  line  or  area  (circle) .  This  will  permit  the  user  in 


future  queries  or  searches  against  that  area  to  refer  to  it 
by  the  given  name  instead  of  inputting  several  strings  of 
coordinates.  Named  areas  of  interest  will  be  normally  estab¬ 
lished  by  echelons  having  the  requirement  to  retrieve  data 
on  given  parameters. 

d.  Staff  Working  File  (SWF) 

The  SWF  should  provide  the  staff  member-user  with 
the  capability  to  enter,  process,  store  and  retrieve  data 
which  does  not  logically  fit  into  other  SACS  files.  It  will 
provide  the  user  the  ability  to  create  new  files  to  meet  new 
or  changing  conditions. 

e.  Terrain  File  (TF) 

The  TF  should  contain  terrain  characteristics 
and  the  results  of  terrain  analysis  in  terms  of  tactical 
evaluation,  that  is,  critical  terrain,  obstacles,  observation 
traf f icability ,  and  cover  and  concealment.  This  data  will  be 
available  to  all  SACS  users  and  will  be  graphic  displays  to 
supplement  or  highlight  the  map  backgrounds.  The  terrain 
data  will  be  provided  by  the  topographical  department.  Staff 
members-users  would  add  other  data  to  supplement  the  file. 

f.  Weather  File  (WF) 

The  WF  should  contain  weather  characteristics  and 
the  results  of  weather  analysis  in  terms  of  the  weather  impact 
on  the  operations.  This  data  will  be  available  to  all  SACS 
users  and  will  be  textual  displays.  The  weather  data  will  be 
provided  by  the  meterological  department. 


g.  On  Line  Query  System  (OQS) 


The  OQS  should  be  a  retrieval  language  which  must 
provide  the  SACS  user  with  the  capability  to  define  retrieval 
parameters  and  report  output  formats.  Retrieval  parameters 
will  be  specified  in  terms  of  field  identifiers,  relational 
operators,  and  data  values.  Print  and  display  commands  should 
specify  the  output  media  and  format.  The  user  should  be  able 
to  sort  the  output,  sum  numeric  quantities,  count  the  number 
of  records  meeting  search  criteria,  and  perform  periodical 
summaries . 

h.  Center  to  Center  Communications  (CCC) 

The  CCC  process  should  permit  correspondence 
between  LMC  central  processors  of  dependent  LAFs.  Messages, 
summaries,  and  processed  reports  could  be  dispatched  or  re¬ 
quested.  The  requirements  for  passing  information  from  the 
lower  LAF  to  the  higher  headquarters  would  normally  be  estab¬ 
lished  by  directive. 

4 .  The  Training  Support  Software 

It  is  logical  to  assume  that  the  LAF  in  garrison  would 
want  to  use  SACS  in  a  training  capacity.  To  be  able  to  accom¬ 
plish  training,  SACS  should  contain  a  training  support  package 
which  can  be  used  to  satisfy  a  variety  of  training  needs  like 
the  command  post  exercises,  component  training  exercises, 

LAF's  software  checkout,  and  operational  readiness  evaluations 
To  satisfy  these  needs,  the  training  support  software  should 
contain  the  following  items. 
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a.  The  Simulation  Package 

The  basic  design  of  the  simulation  should  be  able 
to  accommodate  two  or  more  LAFs  exercising  in  their  superior 
LAF  environment,  a  LAF  exercising  by  itself,  or  the  LAF's 
staff  training  by  itself.  The  simulation  package  must  permit 
battle  simulation  in  a  detailed  event-sequenced  logic  and  in 
an  interactive  way.  This  package  also  should  provide  realis¬ 
tic  insights  into  the  intelligence  information  processing  and 
decision  making  on  the  modern  battlefield. 

b.  The  Data  Reduction  Program 

The  data  reduction  program  should  be  used  to  screen 
the  log  tapes  and  extract  the  mission  essential  elements  of 
analysis  for  the  particular  mission  being  conducted.  Through 
analysis  support,  this  data  could  be  refined,  analyzed,  and 
assembled  in  appropriate  feedback  form  for  presentation  to  the 
participating  staff  personnel.  The  data  reduction  could  be 
designed  so  as  to  be  used  during  software  checkout  to  assure 
operators  that  the  operating  system  is  performing  up  to  speci¬ 
fications.  Support  algorithms  could  also  be  included  to  pro¬ 
vide  the  capability  of  trend  analysis,  comparative  analysis, 
and  to  measure  overall  system  performance . 

c.  On-Console  Training  Program 

The  on-console  training  program  should  be  loaded 
on  SACS  and  used  for  training  of  the  respective  staff  personnel 
in  performance  of  their  operational  responsibilities.  An 
embedded  training  program  should  also  provide  evaluation  of 


the  results  of  the  training  and  maintenance  of  training  con¬ 
duct  records. 

5 .  Software  Distribution  Matrix 

The  distribution  matrix  should  permit  the  automatic 
distribution  of  SACS  messages  based  on  specified  message 
characteristics.  A  message  originator  must  designate  the 
message  addressees  either  by  entering  the  code  name  for  each 
desired  addressee  or  by  entering  a  single  value  code  that 
represents  a  discrete  operator-created  distribution  list  of 
addressees . 
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Figure  2.3:  Mapping  o£  Detection  Systems  on  the  LDP. 


Figure  2.5s  Personnel  Workstation  (Up). 


Intelligence  or  Logistics  Workstation  (Down). 
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III .  WORKING  WITH  THE  SACS  [1,4] 

A.  PERSONNEL  FUNCTIONS 

The  personnel  functions  will  be  performed  from  the  corres¬ 
ponding  workstation.  The  basic  capabilities  of  data  exchange, 
data  management  and  simple  graphic  displays  will  be  available 
to  support  the  function.  The  personnel  functions  will  have 
restricted  use  of  SACS  because  only  a  few  of  them  are  tactical 
in  nature . 

B.  INTELLIGENCE  FUNCTIONS 

The  intelligence  functions  will  be  performed  from  the 
corresponding  workstation.  The  capabilities  of  data  exchange, 
data  management,  analysis  assistance,  interface  with  detection 
systems  and  color  graphic  displays  will  be  available  to  sup¬ 
port  the  function.  The  new  workstation  will  be  used  to  re¬ 
ceive  combat  information  and  intelligence  messages,  retrieve 
LMC  and/or  GESS  graphic  displays  and  digital  data  requested 
by  the  chief  of  staff,  and  to  retrieve  and  manipulate  SACS 
data  for  evaluating,  analyzing  and  interpreting  combat  infor¬ 
mation.  Most  coordination  within  the  LAF ' s  comman  post  should 
be  accomplished  verbally  or  by  using  hard-copied  outputs  be¬ 
cause  this  form  of  communication  is  most  efficient  because  of 
the  close  proximity  of  the  staff  personnel.  Control  of  the 
content  of  analysis  product  files  should  be  under  the  intelli¬ 
gence  subsystem  to  avoid  confusion  and  possible  contradictions 
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Within  the  LAF  command  post  the  intelligence  functions 
are  performed  by  several  staff  sections.  The  intelligence 
operations  functions  will  use  SACS  primarily  to  be  on  line 
with  the  current  tactical  situation  and  terrain  data  from  the 
corresponding  files.  Also  supervising  intelligence  dissemina¬ 
tion,  coordinating  the  intelligence  collection  assets,  and 
determining  intelligence  needs  will  require  access  to  LMF 
and  GESS  graphic  displays  and  file  data.  Preparation  of  the 
intelligence  annex  and  the  formal  staff  briefings  will  require 
the  creation  of  graphic  displays  as  well  as  the  gathering  of 
current  situation  data.  The  intelligence  analysis  and  produc¬ 
tion  function  will  be  performed  using  every  SACS  capability. 
SACS  will  be  used  to  store  combat  information.  Maneuver  units, 
collection  agencies  and  detection  systems  will  be  able  to 
enter  combat  information  directly  into  the  SACS  enemy  situation 
files.  The  SACS  features  of  query,  filtering  and  correlation 
will  be  used  to  confirm,  correlate  and  organize  the  combat 
intelligence  into  a  form  suitable  for  tactical  analysis.  The 
terrain  and  weather  data  will  be  used  to  create  graphics  dis¬ 
plays  showing  key  terrain,  obstacles,  observation  and  firing 
abilities,  cover  and  concealment,  accompanied  with  weather 
impact  texts.  This  data  augmented  with  those  of  the  enemy 
order  of  battle,  can  be  used  to  determine  possible  avenues  of 
enemy  approach.  This  data  also  will  have  utility  in  develop¬ 
ing  plans  of  action  and  tactical  maneuvers,  and  for  logistics 
subsystem  in  developing  supplying  routes  and  locating  depots. 


The  enemy  order  of  the  battle  analysis  will  be  elaborated 
using  SACS.  Enemy  situation  data  will  be  used  for  determining 
enemy  unit  identification,  composition,  disposition  and  strength 
The  current  enemy  order  of  the  battle  can  be  compared  with  the 
corresponding  past  records  to  determine  and  display  unit 
identifications,  enemy  units  arrangement,  enemy  unit  disposi¬ 
tion  and  enemy's  course  of  action. 

The  enemy  situation,  order  of  battle  and  terrain  files 
will  require  management.  Historical  records  and  terrain  and 
v.eather  features  in  the  LAF '  s  area  that  are  no  longer  needed 
will  be  deleted.  The  enemy  situation  file  can  grow  larger 
than  any  other  file  and  it  must  be  closely  supervised  to  avoid 
system  overloads.  The  necessary  deletions  can  be  automatically 
done,  based  on  the  criterion  of  age.  Threshold  indicators 
must  indicate  the  critical  file  size  and  must  initiate  an 
automatic  file  pruning  to  maintain  an  acceptable  file  size 
without  ignoring  the  usefulness  and  the  meaningfulness  of 
the  file  contents. 

The  intelligence  reconnaissance  and  surveillance  function 
will  use  the  SACS  to  process  requests  for  preplanned  recon¬ 
naissance  flights  and  to  monitor  the  ground  reconnaissance 
and  surveillance  activities. 

The  security  functions  will  use  SACS  to  receive  intelli¬ 
gence  collection  tasking  messages  which  will  be  translated 
into  specific  signal  intelligence  indicators  to  be  used  in 
tasking  army  security  agency  field  teams.  The  signal  security 


function  involves  monitoring  friendly  non-secure  communications 
to  ascertain  what  information  is  being  passed  that  might  be 
of  use  to  the  enemy.  SACS  communications  must  be  over  secure 
channels  which  will  not  be  subject  to  monitoring. 

Figure  3.1  presents  a  gross  data  flow  diagram  for  the 
intelligence  subsystem  using  SACS. 

C.  OPERATIONS  FUNCTIONS 

The  operations  functions  will  be  performed  from  the  corres¬ 
ponding  workstation.  The  capabilities  of  data  exchange,  data 
management,  analysis  assistance,  color  graphic  displays  and 
war  games  for  training,  will  be  available  to  support  the  func¬ 
tion.  The  new  workstation  will  be  used  in  developing  the 
friendly  situation,  unit  status,  tactical  estimate,  maneuver¬ 
ing  forces  control,  and  supervision  of  operations  in  compliance 
with  the  General's  decisions.  The  overall  LAF's  operational 
status  will  be  developed,  stored  and  displayed  and/or  printed 
on  demand.  Tasks  organization  for  supporting  the  maneuvering 
forces  should  be  extracted,  presented  and  reviewed  as  part  of 
the  operational  status.  The  SACS  database  will  be  used  to 
assemble  an  overall  operations  estimate  for  the  Commanding 
General.  The  input  sources  for  developing  this  estimate  will 
be  the  enemy  situation  information  as  they  have  been  filtered, 
evaluated,  and  correlated  by  the  intelligence  subsystem;  the 
battlefield  information  about  the  friendly  forces  as  they  will 
be  submitted  in  periodical  reports  by  the  subordinate  echelons 
of  the  LAF;  other  information  arriving  from  other  friendly 


sources  as  the  superior  or  adjacent  LAF .  All  this  data  must  be 
logically  augmented  by  the  existing  relevant  database,  in 
displays  and/or  hardcopies.  Free  text  summaries  must  be 
added  to  explain  the  graphical  presentations  and  both  graphics 
and  displays  will  form  the  operations  estimate  required  by 
the  General.  Supportive  courses  of  action  can  also  be  pre¬ 
pared  and  presented  along  with  the  estimate.  The  course  of 
action  should  include:  the  type  of  action  to  be  taken,  time 
the  action  will  begin,  location  of  the  action,  use  of  the 
available  means  and  purpose  of  the  action.  Changing  tactical 
requirements  needed  to  support  the  maneuvering  plan,  task 
organization,  fire  and  engineering  support  will  be  detected 
by  monitoring  of  the  superior  LAF  networks  and  SACS  situational 
displays.  As  tactical  changes  are  identified,  they  need  to 
be  assessed  in  terms  of  criticality  and  developed  into  appro¬ 
priate  courses  of  action.  Approved  plans  must  be  formed  into 
orders,  modified  operations  overlays,  and  updated  SACS  files 
necessary  to  implement  the  approved  plan. 

The  operations  subsystem  tactical  planners  must  use  its 
workstation  to  develop  on  consoles,  future  courses  of  action 
to  satisfy  the  General's  guidance.  Graphically  developed 
courses  of  action  may  be  assembled  and  stored  in  planning 
files  and  briefed  to  the  General  using  the  LDP  console. 
Graphical  and  textual  compositions  will  be  invaluable  in 
generating  and  storing  courses  of  LAF's  action  to  different 
tactical  situations.  Here  it  must  be  remembered  that 
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unforeseen  enemy  action  can  decoordinate  the  LAF.  The  above 
composition  will  prevent  such  an  undesirable  situation  and  it 
will  contribute  to  the  stability  of  the  system  (LAF) . 

Operations  subsystem  will  use  its  workstation  to  maintain 
the  current  estimate  by  quering  and  establishing  information 
requests  against  the  database.  Assembled  data  can  be  organized 
graphically  to  demonstrate  enemy  and  friend  frontlines,  boun¬ 
daries  of  echelons,  command  posts  and  tactical  maneuvering 
positions,  barriers  and  obstacles,  nuclear  and  chemical  strikes. 

Preplanned  air  support  requests  should  be  processed  using 
the  staff  working  file.  The  air  support  planning  will  be  helped 
considerably  by  the  displays  on  the  LDP  of  the  detection  sys¬ 
tems,  display's  graphical  and  textual  information  about  the 
air  tactical  situation,  giving  the  target  itself;  route, 
height,  and  speed  of  flight;  identification  of  friend,  foe, 
unknown,  etc.  This  way  the  planner  will  have  complete  and 
precise  information  on  how  much  an  echelon  or  area  suffers  from 
enemy  air  force  attacks,  a  fact  which  is  of  high  importance 
in  planning  air  support  requests. 

Figure  3.2  presents  a  gross  data  flow  diagram  for  the 
operations  subsystem  using  SACS. 

D.  LOGISTICS  FUNCTIONS 

The  logistics  functions  will  be  performed  from  the  corres¬ 
ponding  workstation.  The  capabilities  of  data  exchange,  data 
management,  analysis  assistance  and  graphic  displays  will  be 


available  to  support  the  functions.  The  system  graphics  will 
be  used  to  form  the  displays  and  hardcopies  of  significant 
logistical  events  for  briefing  the  General.  These  displays 
showing  obstacles,  key  terrain,  roads,  rivers,  air  strips, 
friendly  and  enemy  unit  locations,  will  be  used  to  determine 
the  main  supply  route  and  supply  points.  Once  developed,  all 
this  information  will  be  stored  in  SACS  files  for  future 
reference.  Area  damage  control,  maintaining  the  status  of 
supplies,  vehicles,  and  equipment  necessary  for  the  accomplish 
ment  of  the  mission  will  be  handled  using  SACS.  Data  will  be 
gathered  and  organized  by  SACS  and  algorithms  will  be  provided 
to  perform  the  statistical  analysis  requirements  of  logistics. 


Collodion 


Figure  3.2!  Operations  Subsystem 


SECURITY  AND  SACS  [6,7,8] 


A.  SACS  SECURITY  INTO  PERSPECTIVE 

Computer  fraud  and  abuse  in  the  private  sector  creates 
newspaper  headlines  since  these  crimes  usually  involve  large 
amounts  of  money.  But  analogous  crimes  in  a  military  system 
(e.g.,  SACS)  may  go  completely  undetected,  even  though  the 
potential  for  damage  to  the  national  security  is  much  more 
serious.  The  reason  for  this  lack  of  detection  is  that  when 
information  is  leaked  electronically  it  does  not  disappear; 
the  original  remains  intact  and  unaltered  and  there  may  be 
no  evidence  that  it  has  been  copied. 

Computer  systems  have  not  been  very  good  at  keeping  secrets 
It  is  too  easy  to  demonstrate  that  an  opponent  can  penetrate 
the  protection  mechanism  of  typical  operating  systems,  gain 
control  of  the  machine,  and  obtain  any  information  he  wishes. 
The  only  reliable  approach  is  to  prevent  an  opponent  from 
gaining  access  to  the  computer  system.  This  can  be  typically 
accomplished  by  locking  up  the  computers  and  clearing  all  the 
people  who  use  them  to  the  level  of  the  most  sensitive  data 
on  the  machine.  This  approach  is  at  least  inconvenient. 
Operational  problems  occur  when  information  cannot  be  made 
available  quickly  to  users  who  need  it  because  of  too  tight 
restrictions  on  access  to  the  system.  For  this  reason,  several 


models  of  computer  security  have  been  developed  in  the  past 


which  must  be  the  milestone  concepts  in  SACS  security.  These 
concepts  are  briefly  discussed  below. 


1 .  Basic  Security  Condition 

The  basic  security  condition  has  to  restrict  a  user 
from  reading  information  classified  above  his  clearance.  Thus 
the  system  must  keep  track  of  the  levels  and  compartments 
associated  with  the  files  used  by  a  job  during  a  session. 
Whenever  a  new  file  is  created,  it  must  be  marked  with  the 
appropriate  security  level  and  all  the  compartments  of  the 
file  used  so  far.  Only  certain  authorized  users  will  be  able 
to  access  information  of  a  corresponding  classif ication  level. 

2 .  Access  Matrix 

The  access  matrix  has  to  describe  the  system  in  terms 
of  its  subjects  and  objects.  Subjects  are  usually  processes 
operating  at  the  direction  of  a  user.  Objects  are  files  and 
the  kinds  of  access  that  subjects  may  have  to  files.  Sub¬ 
jects  will  be  listed  as  the  rows  of  a  matrix  and  the  objects 
as  its  columns,  so  each  entry  of  the  matrix  tells  what  access 
a  subject  is  allowed  to  an  object. 

3 .  Security  Kernel 

The  security  kernel  exploits  the  concept  of  a  "reference 
monitor"  as  a  basis  for  developing  a  secure  operating  system. 

The  reference  monitor  would  check  each  reference  by  a  subject 
to  an  object  and  be  sure  that  it  is  authorized  by  the  access 
matrix.  The  mechanism  that  handles  the  reference  monitor  has 
to  be  tamperproof,  invoked  on  every  reference,  and  subjected 


to  complete  analysis  and  test.  The  security  kernel  of  the 
SACS  must  be  composed  of  its  reference  validation  mechanism, 
access  control,  security-related  functions  and  nothing  else. 
Two  axioms  must  govern  the  security  kernel  concept:  (a)  No 
user  may  read  information  classified  above  his  clearance, 
and  (b)  No  user  may  lower  the  classification  of  information 
(no  "Read  Up,"  no  "Write  Down"). 

B.  SECURITY  AND  THE  LIFE  CYCLE  OF  SACS 

For  a  developer  embarking  on  a  new  project  that  requires 
a  system  like  SACS  to  restrict  some  of  its  information  from 
some  of  its  users,  there  still  is  no  approach  that  guarantees 
absolute  success.  To  assume  invulnerability  of  SACS  as  a 
result  of  a  good  security  program  is  like  assuming  that  a  car 
will  never  run  out  of  gas  because  it  has  a  gas  gauge.  However 
a  good  security  program  is  a  necessity  and  there  are  at  least 
three  doctrines  for  the  SACS  developer  who  faces  the  need  to 
separate  computer  users  with  different  clearances  and  data 
with  different  classifications.  These  three  most  significant 
doctrines  are  strongly  related  to  the  SACS  life  cycle. 

1 .  Security  and  the  Study  Phase 

The  security  requirements  of  the  SACS  must  be  con¬ 
sidered  together  with  its  functional  requirements.  Security 
is  not  something  that  can  be  added  to  an  existing  design  even 
though  often  security  seems  separate  from  function.  The 
intelligence  subsystem  must,  for  example,  deliver  tactical 
information,  and  security  imposes  the  constraint  that  certain 


parts  must  not  be  delivered  to  the  logistics  subsystem.  It 
is  tempting  to  divorce  the  function  from  the  constraint. 

Viewed  at  the  top  level,  however,  the  requirement  is  for  a 
system  that  delivers  the  intelligence  information  in  a  way 
that  does  not  compromise  it.  Security  requirements  can 
affect  the  entire  structure  of  the  SACS  software  and  thus  needs 
to  be  considered  at  the  highest  level  of  design. 

2 .  Security  Throughout  the  Design  and  Development  Phase 
It  is  crucial  to  identify  and  state  the  security  re¬ 
quirements  clearly.  But  it  is  still  necessary  to  pay  close 
attention  to  the  techniques  used  in  designing  and  building 
the  SACS.  The  functions  of  the  SACS  must  be  studied,  focusing 
on  the  requirements  for  the  flow  of  classified  information, 
and  on  the  conditions  under  which  classified  information  is 
to  be  disclosed,  modified,  reclassified  or  to  enter  or  leave 
the  SACS.  The  first  step  can  be  a  simple  informal  but  precise 
model  of  the  information  flow  and  authority  in  the  SACS.  Such 
a  model  could  help  both  developers  and  users  in  understanding 
what  is  to  be  enforced.  The  second  step  must  be  the  use  of 
hierarchical  specifications  for  the  design.  A  top  level 
specification  that  will  reflect  the  SACS  structure  and  infor¬ 
mation  flow,  as  well  as  a  program  specification  to  allow 
personnel  to  review  and  assess  the  information  flow  and 
authorization  mechanisms,  should  be  included  in  these  hierachi 
cal  specifications.  The  third  step  must  be  the  choice  of 
hardware  that  reduces  security  problems.  Generally  hardware 


should  provide  good  mechanisms  for  isolating  different  compu¬ 
tations,  simple  and  efficient  ways  to  control  the  flow  of 
information  between  isolated  contexts,  and  a  uniform  way  of 
treating  different  kinds  of  objects  (e.g.,  SACS  files). 

Features  such  as  virtual  memory,  a  device  interface  that 
offers  the  possibility  of  a  uniform  treatment  of  memory,  and 
the  ability  to  change  addressing  contexts  rapidly  will  help 
in  the  implementation  of  a  secure  SACS.  Several  machine 
states  that  restrict  access  to  critical  portions  of  the  instruc 
tion  set  are  not  required  if  all  accesses  to  data  are  mediated 
by  the  virtual  memory  mechanism,  but  they  should  be  used  as 
another  way  of  protecting  critical  operating  system  data,  for 
example  the  contents  of  the  mapping  registers.  The  fourth 
step  must  be  the  choice  of  programming  languages  for  which 
there  exists  a  reliable  and  well  verified  compiler.  The  final 
step  must  be  the  construction  of  test  plans  with  specific 
attention  to  the  security  requirements  of  the  system.  Testing 
is  an  important  way  of  establishing  confidence  that  the  con¬ 
trols  implemented  are  in  fact  effective. 


Systems  like  SACS  that  must  enforce  military  security 
often  have  a  requirement  that  others  lack.  Not  only  must  the 
builder  and  the  user  be  satisfied  with  the  correct  functioning 
of  the  system,  but  it  must  be  possible  to  convince  the  certi¬ 
fying  agent  that  this  is  in  fact  the  case.  This  consideration 
makes  it  imperative  that  the  software  be  designed,  implemented, 
and  documented  according  to  software  engineering  principles. 


C.  SURVIVABILITY  OF  THE  SACS 

One  very  important  feature  which  must  characterize  SACS  is 
its  survivability  after  a  possible  component  failure.  It  is 
easily  understood  how  destructive  the  unavailability  of  SACS 
would  be  in  a  case  where  the  tactical  situation  does  not  permit 
a  rapid  switching  to  the  manual  system.  So  one  criterion  for 
designing  a  highly  secure  SACS  is  to  ensure  its  continued 
reliable  operation  and  availability.  A  survivable  SACS  should 
provide  for  "grateful  degradation; "  a  SACS  with  failed  com¬ 
ponents  should  continue  to  provide  service  even  at  reduced 
levels.  A  survivable  SACS  should  be  designed  so  that  a  failed 
component  could  be  taken  off-line,  repaired  and  placed  back 
on-line,  all  while  the  system  should  provide  uninterrupted 
service.  One  key  for  SACs  survivability  must  be  "redundancy." 
If  a  component  fails,  then  an  equivalent  component  must  pick 
up  the  slack.  Multiprocessing  will  be  important  in  any 
survivable  SACS.  Other  features  which  should  be  considered 
in  order  to  achieve  survivability  of  SACS  are: 

1.  Incorporation  of  fail-safe  mechanisms  into  the  firmware 
rather  than  in  software 

2.  Use  of  transparent  multiprocessing;  this  allows  perfor¬ 
mance  upgrades  without  software  modifications 

3.  Use  of  multiple  input/output  subsystems 

4.  Incorporation  of  major  portions  of  the  operating  system 
into  hardware 

5.  Incorporation  of  fault  detection  mechanisms  into  the 
hardware  and  software. 
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D.  NETWORKING  THE  SACS  WITH  SECURITY 

It  has  been  stated  in  Chapter  II  that  a  SACS  is  expected 
to  exchange  data  with  other  tactical  data  systems.  This  ex¬ 
pectation  can  be  met  by  networking  the  SACSs  of  related  LAFs 
using  the  packet  switching  technique.  The  means  for  attaining 
security  in  the  packet  switched  communications  system  is  the 
concept  of  the  end-to-end  encryption.  An  end-to-end  encryp¬ 
tion  is  an  apparent  need  in  order  to  protect  the  exchanged 
information  since  all  the  exchanged  messages  will  be  out  of 
the  physical  control  of  the  communicators.  In  an  end-to-end 
encryption,  the  sender  encrypts  the  message  and  it  remains 
encrypted  while  being  transmitted  through  a  network  until  it 
is  received  and  decrypted  by  the  receiver.  A  device  called 
a  PLI  (private  line  interface)  should  be  placed  between  the 
host  LMC  and  the  packet  switches  as  it  is  shown  in  Figure  4.1. 
Figure  4.2  shows  the  PLI  layout.  The  PLI  will  encrypt  the 
data  in  each  packet,  leaving  the  header  in  the  clear.  The 
switches  will  route  the  packets,  but  the  actual  data  will  be 
encrypted.  As  a  result,  when  packets  will  pass  throught 
the  switches,  operators  will  not  be  able  to  examine  the  data 
in  encrypted  form  nor  will  misrouted  packets  be  able  to  divulge 
classified  data.  All  the  switches  must  be  placed  in  military 
sites  and  can  be  manned  by  the  same  cleared  personnel  who 
maintain  the  SACS.  The  encryption  devices  will  be  keyed  by 
using  the  same  keys  for  a  user  community  and  different  keys 
for  other  communities;  in  this  way  the  communications  system 


will  be  partitioned  into  "communities  of  interest."  The 
maintenance  of  the  switches  can  be  performed  by  the  operators 
of  the  nearest  SACS  being  interconnected.  The  switches 
themselves  are  computers  quite  small  and  inexpensive,  and  about 
as  complicated  as  a  peripheral  controller.  Since  the  tech¬ 
nology  and  complexity  is  about  that  of  a  small  piece  of  digital 
gear,  the  additional  maintenance  load  on  the  SACS  operators 
will  be  quite  small.  The  PLIs  can  be  collocated  with  the 
SACS  terminals,  or  if  multiplexers  or  concentrators  are  used, 
the  PLIs  can  be  placed  at  the  access  point  to  the  switch, 
provided  that  multiplexers  and  concentrators  are  multilevel- 
secure  and  that  the  terminals  are  all  secure  as  needed. 


Figure  4.1s  End-to-End  Encryption  Using  PLIs 


FACING  THE  END  USER  PROBLEM  [7,9,10,11] 


A.  THE  END  USERS  OF  THE  SACS 

When  SACS  is  introduced,  it  will  be  necessary  that  cer¬ 
tain  principles  of  automated  systems  should  be  understood  by 
the  LAF  commander,  staff  members  and  other  end  users  who  will 
be  affected  by  it.  To  a  large  extent  success  or  disappoint¬ 
ment  is  dependent  on  these  end  users,  their  involvement  in 
the  definition  and  logical  modeling  of  the  data,  their  employ¬ 
ment  of  end-user  database  language  and  their  acceptance  of  the 
results  and  the  principle  of  shared  data. 

The  term  "end  user"  is  used  to  describe  someone  who  inter¬ 
acts  with  a  computer  in  one  way  or  another.  This  term  is  too 
broad  and  covers  an  enormous  range  of  skills  and,  unless  it 
is  further  qualified,  may  be  used  to  describe  almost  anyone 
in  the  LAF  that  will  use  the  SACS  in  some  kind  of  data  proces¬ 
sing.  It  is  worth  listing  the  ways  in  which  a  person  may  be 
considered  an  end  user. 

1 .  The  Recipient  of  Regular  SACS-Generated  Reports 

Nearly  everyone  connected  with  some  form  of  automatic 
data  processing  uses  such  forms.  Frequently  these  reports  are 
adequate  to  the  needs  of  the  reader.  However,  it  is  often 
the  case  that  hours  are  wasted  in  performing  simple  analyses 
that  could  easily  have  been  performed  by  the  program  that 
generated  that  report. 


2 .  Application  Programmers 


Although  there  would  appear  to  be  no  limit  to  the 
ability  of  an  application  programmer  to  obtain  the  desired 
data,  this  is  frequently  not  the  case.  An  application  pro¬ 
grammer,  because  of  the  amount  of  technical  programming  detail 
that  must  be  mastered,  is  frequently  "locked"  into  one  system; 
a  computer,  programming  language  or  operating  system.  A  lack 
of  understanding  between  the  applications  programmer  and  the 
person  who  uses  his  results  is  a  major  cause  of  frustration 
and  delays. 

3 .  Users  of  Interactive  Database  Query  Languages 

Such  users  will  be  the  majority  of  the  SACS'  users. 
Their  ability  to  extract  the  data  they  want  will  be  limited 
by  the  power  of  the  query  language  and  their  skill  at  using 
it.  The  problem  is  that  there  is  no  standard  query  language 
and  such  users  may  have  to  learn  different  languages — something 
that  could  be  avoided.  This  is  the  main  topic  of  this  chapter. 
The  use  of  a  good  general-purpose  database  query  language 
will  be  of  general  benefit  because  it  will  be  easy  for  naive 
end  users  to  learn,  and  because  it  will  provide  the  rapid 
access  to  data  and  quick  writing  of  application  programs  that 
these  users  require . 

B.  THE  QUERY  LANUAGE 

A  mistake  that  is  frequently  made  is  to  confuse  the  com¬ 
plexity  of  a  language  with  its  power.  If  the  power  of  a 
language  refers  to  its  ability  to  control  the  hardware  on  which 
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it  is  run,  this  confusion  may  be  justified  because  the  current 
hardware  is  inherently  complicated.  However  if  power  means 
the  ability  to  provide  an  abstract  description  of  a  compu¬ 
tational  process,  there  is  no  reason  that  this  should  entail 
a  language  with  complicated  syntax  or  constructs.  LISP  and 
PROLOG  may  not  be  the  ideal  languages  for  end  users  in  the  LAF 
community,  but  they  are  among  the  most  powerful  (in  the  second 
sense)  and  there  aren't  languages  with  a  simpler  syntax. 

Database  access  languages  may  be  broadly  divided  into  those 
that  are  powerful  but  difficult  to  learn,  and  those  that  are 
limited  but  easy  to  learn.  However  there  is  a  non-procedural 
(so  very  easy  to  learn)  query  language  which  is  quite  power¬ 
ful  also.  This  is  Query-By-Example  (QBE)  which  is  associated 
with  the  relational  database  model. 

It  is  desirable  that  the  staff  member  (being  generally  a 
naive  user)  approaching  a  terminal  should  be  required  to  know 
as  little  as  possible  in  order  to  get  started.  He  may  have  to 
know  a  little  more  in  order  to  use  the  subtleties  of  a  language, 
but  this  also  should  be  minimized.  He  may  approach  a  database 
knowing  very  little  about  the  names  of  the  records,  of  fields 
(attributes) ,  or  how  to  access  them.  The  best  means  of  ex¬ 
plaining  the  user  language  functions  is  by  examples.  Various 
psychological  studies  of  QBE  have  shown  that  naive  users  acquire 
the  skill  to  make  complicated  queries  in  less  than  three  hours. 
The  language  is  designed  with  the  excellent  principle  that 
the  thinking  process  the  user  follows  is  the  same  as  he  would 


use  to  find  the  same  information  without  a  computer.  More¬ 
over,  the  effectiveness  of  QBE  will  never  disappoint  a  staff 
member  who  happens  to  know  a  lot  about  computers  and  database. 

There  are  certain  extensions  of  QBE  like  the  QBPE  (Query 
by  Picture  Example)  that  could  be  extremely  useful  for  staff 
members  if  they  want  to  create  graphs  with  map  areas  such  as 
the  maneuver  plans  for  example.  Another  extension  of  QBE 
is  the  PBE  (Procedures  by  Example)  which  covers  a  wide  area 
of  SACS  applications.  QBPE  is  based  on  an  integrated  database 
system  interfaced  with  an  image  analysis  system.  By  using 
pattern  recognition  and  image  processing  manipulation  func¬ 
tions,  pictorial  descriptions  can  be  extracted  from  images. 

These  extracted  descriptions  and  inherent  registrations  of 
pictures  are  then  integrated  into  a  relational  database;  the 
original  two-dimensional  pictures  are  kept  in  a  separate  picture 
store.  Thus,  queries  concerning  pictures  can  be  manipulated 
through  the  relational  database,  eliminating  the  need  to 
process  vast  amounts  of  imagery  data.  If  a  user's  request 
can  be  expressed  in  terms  of  the  extracted  picture  descrip¬ 
tions,  there  is  no  need  to  retrieve  and  process  the  original 
pictures.  If,  on  the  other  hand,  the  stored  information  is 
not  sufficient,  all  pictures  satisfying  selection  criteria  can 


^J.  Ullman  in  his  book  Data  Base  Principles,  CSP  1982, 
pp.  207-208,  proves  the  power  of  QBE. 

J.  Martin,  in  his  book  An  End  User  Guide  to  Data  Base, 
1983,  pp.  99-101,  presents  170  lines  of  a  COBOL  program  for 
an  inquiry  that  can  be  handled  with  one  screen  by  QBE. 
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be  retrieved  from  the  picture  store  and  processed  until  the 
required  precision  is  obtained.  Figure  5.1  presents  the  data¬ 
flow  diagram  of  the  QBPE  background.  Using  QBPE  is  the  SACS, 
most  queries  could  be  specified  from  relations  which  will  be 
parts  of  a  database  comprised  of  land  images  and  digitized 
maps.  In  Office  Procedures  by  Example  (OPBE)  there  are 
primarily  four  major  components  beyond  the  QBE  database  manage¬ 
ment  system,  some  of  which  are  generalizations  of  the  QBE 
facilities . 

1 .  Generalized  Data  Objects 

Whereas  the  fundamental  data  object  in  QBE  is  a  table, 
in  OPBE  the  objects  are  forms,  reports,  charts  and  documents, 
all  of  which  can  be  created,  edited  and  sent  to  other  nodes 
of  the  system. 

2 .  Communication  Subsystem 

In  order  to  communicate  in  the  form  of  the  above 
described  objects  to  various  nodes  of  the  system  (such  as  the 
related  LAFs  being  connected  through  a  network) ,  we  must  have 
a  communication  subsystem.  For  each  node  of  the  network  there 
exists  a  local  database  with  the  ability  to  access  centrally 
shared  databases. 

3 .  Triggers 

A  basic  necessity  in  any  office  automation  is  the 


ability  of  the  system  to  take  automatic  actions  whenever 
certain  conditions,  times  or  events  are  met.  In  doing  so  the 
user  can  automate  much  of  the  routine  procedures,  thus  devoting 


his  time  to  more  advanced  tasks.  The  following  are  some 
actions  that  we  may  want  to  automate: 

Deferring  of  certain  messages 
Creation  of  various  logs 

Automatic  inventory  replenishment  requests 
Follow-up  procedures  (for  example  if  an  answer  is  not 
received  within  2  hours,  the  user  will  be  alerted) . 

Complicated  boolean  and  arithmetic  operations  can  be 
formulated  using  the  condition  boxes  of  the  OPBE  &  OBPE. 

The  text  processing  in  the  OPBE  is  harder  than  that  of 
incorporating  arithmetic.  This  problem  can  be  solved  by  a 
good  interface  between  the  QBE  and  a  suitably  structured 
editor . 

At  the  level  of  the  user  interface  QBE  is  extremely 
well  engineered,  exploiting  color  graphics  and  screen  control 
for  ease  of  data  entry.  It  leaves  the  user  in  no  doubt  about 
the  data  model  (relational)  that  is  in  use;  relations  are 
visible  tables.  The  programming  environment,  the  means  by 
which  data  and  queries  are  stored  and  recalled,  is  also  ex¬ 
tremely  well  thought  out. 

C.  THREE  PROBLEM  SOLVING  SCENARIOS 

To  show  the  utilization  of  the  user  communication  interface 
in  intelligence  production,  three  trivial  examples  of  using 
QBE  and  its  extensions,  are  presented.  The  intention  of  the 
examples  is  to  demonstrate  to  the  staff  members  a  typical 


interaction  session  rather  than  to  present  truly  valid  algorithms 
for  the  corresponding  procedures. 


1 .  Identification  of  Missiles  in  a  Firing  Event 

The  hypothetical  problem  of  the  missile  event  can  be 
described  as: 

a.  Identify  the  missile  as  a  known  configuration 

b.  Identify  the  missile  as  a  new  system 

c.  Produce  a  report  of  the  parameters  of  the  event. 

The  data  available  about  the  event  include: 

a.  Launch  Site:  Rplace,  USSR  Missile  Launch  Facility 

b.  RV  Impact:  Gplace,  Greece 

c.  2  stage  ignition: 

Altitude  =  30  km  over  Bplace,  Bulgaria 
Time  =  . 4  hours 

The  user  sitting  at  the  terminal  is  presented  with 
a  skeleton  of  a  table  on  the  screen: 


(Table  Name)  (Field  Names) 


(1) 


The  user  knows  that  there  is  a  "MISSILE" 
to  know  what  field  exists  in  that  record. 


record  and  he  wants 


I 


So  he  types: 


MISSILE  P. 

"P."  stands  for  "Print."  The  terminal  may  respond  increasing 
the  number  of  columns  as  necessary: 


two  or  more  different  skeletons  on  the  screen  at  once.  He 


In  this  case  the  user  could  insert  the  new  system  as  follows: 


TRAJECTORY 

MTYPE 

' 

TTYPE 

STAGE 

ALTITUDE 

TIME 

I . 

NEW 

p 

2 

30  km 

.4  h 

( 6  ' ) 


MISSILE 

CLASS 

TYPE 

STAGE 

RANGE 

RADIUS 

I . 

UNKNOWN 

NEW 

2 

1500  + 

7 

"I."  is  used  for  insertions.  In  this  last  case,  the  user 
inserts  the  data  he  has  with  respect  to  this  new  system.  In 
the  columns,  he  has  no  data,  so  he  inserts  the  words  "UNKNOWN, 
"NEW,"  "1500+,"  "?."  When  he  obtains  additional  information 
he  can  update  the  records  as  follows  ("U."  is  used  for  update) 


TRAJECTORY 

MTYPE 

TTYPE 

STAGE 

ALTITUDE 

. . . . 

TIME 

U. 

D4 

PARABOLA 

2 

30  km 

.4  h 

(7’) 


Using  QBE  the  user  can  also  delete  data  ("D."),  link  tables, 
retrieve  data  under  conditions  specified  by  him.  The  database 
administrator  can  assign  authorizations  to  certain  users  and 
he  can  also  impose  constraints.  These  control  and  integrity 
features  of  QBE  are  very  desirable  in  the  SACS  case,  and  they 


can  be  elaborated  in  accordance  with  the  SACS  security  general 
fame . 

2 .  Creation  of  a  Graph  of  the  LAF 1 s  Vital  Area 

The  TAC  using  the  QBPE  facilities  can  read  its  color 
map  background  which  can  be  stored  in  a  digital  form  in  a 
separate  picture  store.  Most  queries  would  be  specified  from 

O 

the  following  relations: 

CITIES  ( FRAME, CITY-ID, XI, X2, Yl ,Y2) 

CITYNAME  ( FRAME, CITY-lD, NAME) 

ROAD  (FRAME,  R0-1D,  XA, XB ,YA, YB) 

RO-NAME  ( FRAME, RO -ID, NAME) 

MOUNTAIN  (FRAME , MOUN-lD, XMl , XM2 , XM3 , XM4 , YMl , YM2 , YM3 , YM4 ) 


etc.  including  all  the  necessary  information  for  the 
production  land  features.  X  and  Y  describe  the  required 
corresponding  2D  coordinates.  The  "FRAME"  is  represented 
by  a  number  that  corresponds  to  a  certain  portion  of  the 
original  map  image. 

Suppose  the  user  wants  to  sketch  the  vital  area  within 
certain  boundaries  specified  by  the  land  features.  This  query 
can  be  formulated  as  follows: 


MOUNTAIN 

FRAME 

MO UN- ID 

NAME 

2 

04 

OLYMPOS 

3 

09_ 

OSSA 

7 

2_3 

AIMOS 

8 

For  a  complete  analysis  of  the  concept,  see:  "Picture 
Query  Languages  for  Pictorial  DB  Systems,"  by  N.S.  Chang  and 
K.S.  Fu,  Computer,  November  1981,  pp.  23-33. 
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MOUNTAIN  i  FRAME  j  MDUN-lD  )  XMl  j  XM2  I  XM3  I  XM4  I  YMl  I  YM2  I  YM3  I  YM4 


The  system  will  respond  with  an  intermediate  result  table  for 
all  the  boundary  segments  of  the  vital  area: 


The  user  wants  to  draw  the  roads  which  are  in  the  vital  area 


RO-1D 

NAME 

12 

ETHNIKI 

15 

EGNATIA 

63 

LARISSAS 

ROAD 


FRAME 


2 

3 

4 


The  command  "S."  stands  for  "Sketch"  so  the  user  will  type 
"S."  in  (10)  and  (11)  as  follows: 


XI  Yl 


X 


XN 

YN 

z 

W 

1 

FRAME 


2 

3 


RO-1D 


NAME 


ETHNIKI 

EGNATIA 

LARISSAS 


The  system  will  respond  presenting  on  the  screen  the  sketch- 
picture  of  the  vital  area  with  the  specified  roads.  The  user 
could  ask  for  the  drawing  of  the  rivers,  hills  etc.,  according 
to  his  need.  The  user  exploiting  the  other  graphic  capabili¬ 
ties  of  the  TAC  can  enrich  his  sketch  by  drawing  friendly  and 
enemy  dispositions,  avenues  of  approach,  points  of  interest, 
etc.,  and  by  adding  textual  explanations  for  his  reports. 

Currently  the  pictorial  operators  used  to  contrast 
pictorial  entities  are  as  listed  below: 

Pictorial  Union  of  two  given  regions:  UNI0N-R1R2 
Pictorial  Intersection  of  two  given  regions:  INT-R1R2 
Compute  the  length  of  a  given  line:  LENGTH-L 
Compute  the  perimeter  of  a  given  region:  LENGTH-R 
Compute  the  area  of  a  given  region:  AREA-R 
These  operators  are  intended  to  construct  only  the  basic 
relations  among  points,  lines  and  regions  for  queries  concern¬ 
ing  pictorial  information.  Depending  on  the  application  re¬ 
quirements,  user-supplied  operators  can  be  implemented  for 
more  efficient  operation. 

3 .  Sending  A  Message  to  the  Superior  LAF/G3 

Suppose  that  the  G3  of  our  LAF  wants  to  send  the 

maneuvering  plan  for  approval  to  the  superior  LAF.  This  can  be 

9 

done  using  the  capabilities  of  OPBE  as  follows. 


9 

See  "A  Language  for  Office  &  Business  Automation"  by 
M.  Zloof,  Office  Automation  Conference  Digest,  March,  1980, 


pp.  240-260. 


UNIT 

NAME 

LOCATION 

SENDER 

G3 

L 

A 

NAME:  G3 

LOCATION: 

L 

Subject : 

Maneuvering  Plan 

-  - 

-  -  - 

-  -  -  (TEXT)  ------------- 

_B_ 

NAME:  G3 

LOCATION:  L 


SEwD  A, B  to  G3 


Everything  presented  here  in  plain  English  could  have  been 
encrypted . 

After  presenting  the  new  work  stations  to  the  staff 
members  and  after  explaining  some  of  the  important  user 
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communication  concepts,  they  will  quickly  perceive  the  advan¬ 
tages  of  SACS;  nearly  all  the  information  resources  they 
might  require  are  readily  available  from  their  work  station. 
They  will  be  able  to  retrieve  documents  that  relate  to  their 
job  and  insert  relevant  analysis  products  in  their  reports. 
They  will  be  able  to  generate  messages  and  on-line  reports  for 
those  who  need  to  use  the  results  of  their  work.  They  will 
have  convenient  facilities  for  presenting  and  routing  on-line 
requirements  for  additional  information  collection. 

Whereas  the  staff  member  will  be  in  the  beginning 
mildly  amazed  with  the  versatility  he  has  observed  in  the 
workstation  equipment,  he  will  soon  experience  the  potential 
of  the  new  horizons  offered  by  a  friendly,  trustworthy  and 
obedient  SACS  for  carrying  on  his  tasks. 


Figure  5.1*  Data  Flow  Diagram  of  QBPE. 


VI .  INTELLIGENCE  INFERENCE  AND  DECISION  MAKING  [13] 

A.  THE  MILITARY  INTELLIGENCE  PROBLEM 

It  is  clear  that  every  staff  activity  in  the  LAF  is  ex¬ 
clusively  based  on  the  intelligence  subsystem  during  the 
war  time.  The  operations  and  logistics  plans  are  formed  using 
the  timely  evaluated  information  about  the  enemy's  location, 
strength,  capability,  vulnerability  and  intentions.  If  this 
information  is  accurate  then  we  can  make  good,  more  or  less, 
plans.  But  if  the  information  we  have  is  not  accurate  enough, 
then  it  is  not  possible  to  make  good  plans  and  good  decisions, 
no  matter  how  good  staff  officers  or  inspired  leaders  that 
we  have.  The  old  characterization  of  Clausewitz  seems  to 
still  be  appropriate:  "...a  great  part  of  the  information 
obtained  in  war  is  contradictory,  a  greater  part  is  false, 
and  by  far  the  greatest  part  somewhat  doubtful."  Modern 
improvements  in  intelligence  sensors  have  almost  embarrassingly 
exploded  the  amount  of  data  collected,  but  the  information 
is  still  enormously  variable--mainly  because  this  advance  in 
sensor  technology  has  been  countered  by  enemy  concealment 
and  deception  sophistication.  The  intelligence  expert  cannot 
know  the  location,  activity  and  intention  of  every  unit  in 
the  enemy  army,  but  if  enough  is  located  the  rest  must  be 
inferred.  The  theoretical  question  is--how  much  he  has  to 


know  to  be  able  to  infer  the  rest? 


A  LAF  has  many  sources  of  data.  There  are  the  forward 
units,  observers,  and  patrols  reporting  enemy  type,  activity 
and  strength.  Prisoner  interrogation  and  agents  are  another 
source.  There  are  radio  intercepts,  visual,  magnetic-acoustic 
and  radar  sensors  associated  with  all  LAFs.  The  use  of 
aircraft,  overflying  the  enemy,  generates  another  avalanche 
of  data.  The  intelligence  analyst  must  look  for  signals  in 
the  presence  of  noise  or  deception.  Camouflage  netting  for 
example  tends  to  obscure  the  size,  shape  and  color  of  covered 
objects  from  visual  observation.  The  analyst  must  expand  his 
examination  to  consider  reports  of  other  activities  that  may 
be  germane  to  the  event  of  interest.  A  report  of  an  armored 
brigade  in  the  area,  for  example,  might  give  support  to  the 
belief  that  an  object  under  camouflage  is  a  tank.  There  is 
the  occurrence  of  frequent  transformation  between  the  detec¬ 
tion  of  any  event  and  the  final  assessment.  Figure  6.1  pre¬ 
sents  this  sequence.  The  first  transformation  (P^  n)  occurs 
as  some  sensor  detects  physical  stimuli  received  from  a 
special  characteristic  of  the  target.  The  second  transfor¬ 
mation  (Pc)  takes  place  as  the  interpreter  perceiving  the 
size  and  shape  may  report  possibly  one  armored  vehicle.  The 
third  transformation  (p  )  may  identify  it  as  a  tank;  the  fourth 
(P^)  the  model  and  type  of  tanks  in  the  force.  The  fifth 
(P^+-^)  transformation  might  be  the  identification  of  the 
force  as  the  "X"  Armored  Division  commanded  by  General  "Y". 

If  the  enemy  strategically  places  tank  silhouettes  to  give 
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the  illusion  that  tanks  are  present,  a  whole  series  of  errors 
can  result.  On  the  other  hand,  the  expansion  of  the  probability 
trees  for  the  enormous  numbers  of  events  we  will  have  from  the 
sensors  will  make  the  use  of  SACS  a  brute  force  approach, 
inevitably  prone  to  combinatorial  explosion  if  methodologies 
are  not  applied  to  establish  the  basis  for  the  design  of  an 
appropriate  data  processing  system  for  military  intelligence 
purposes.  Thus  the  objective  of  this  chapter  is  to  develop 
some  mathematical  models  that: 

Can  minimize  the  harmful  effects  of  incomplete  and 
unreliable  data. 

Can  facilitate  the  information  inference  from  the 
existing  data. 

Can  be  the  basis  of  further  research  for  a  better 
simulation  of  the  intelligence  problems. 

B.  THE  TACTICAL  INTELLIGENCE  MODEL 

Suppose  there  is  a  critical  flank  which  must  be  held. 

Let  X  and  Y  represent  the  level  of  forces  on  each  side.  The 
value  of  X  should  be  proportional  to  the  value  of  Y  since  this 
is  imposed  by  the  tactic  doctrines.  In  addition,  the  change 
of  X  force,  because  of  casualties,  is  proportional  to  the 
absolute  size  of  the  opposing  force.  These  relations  can  be 
expressed  by  the  following  equations: 


X  =  kxY 

X I  =  *2Y 
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If  we  add  these  equations  we'll  have: 


X  +  X'  =  (^  +  k2)  •  Y 

If  we  say  that  =  k,  then: 

X  +  X'  =  k-Y  or 

X'  =  k-Y  -  X 

This  equation  assumes  perfect  information  of  X  about  Y.  If 
X  is  not  sure  of  Y  force  level  and  has  to  estimate  or  infer 
from  intelligence  (this  is  often  the  case) ,  this  equation 
can  still  be  used  by  using  estimate  terms  involving  the  mean 
(y)  and  variance  (a) 

X's  estimate  =  Y  (y  ,a  ) 

e  y  y 


Then 


X'  =  k-tYe(yy,ay)]  -  X 

We  can  go  further  and  enrich  the  equations  with  factors  of 
land  morphology,  weather  impact,  etc.,  in  order  to  make  a 
more  representative  model.  Finally  the  general  form  of  this 
equation  will  be: 


X'  =  f(X,Y,Z, . . .) 
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We  can  write  a  FORTRAN  program  to  find  approximate 
solution  to  this  first  order  differential  equation  with 


initial  condition  X  (Y=0)  =  0,  using  Euler's  method.  Euler's 
method  assumes  that  during  the  interval  [  Y , Y+A Y)  ,  X'  remains 
constant  and  that 

AX/AY  =  X'  =  f(X,Y) 

-*•  AX  =  AY  •  f  (X ,  Y)  . 


Thus 


X. 


New 


=  XOld  +  AX  = 


XOld  +  AY’f (XOld,YOld) 


Or  stating  this  as  a  difference  equation: 


X 


i+1 


X±  +  AY- (Xi,Yi) 


(1) 


for  i  =  0,1,..., N.  The  FORTRAN  program  is: 


READ  N,  DELTAY,  Y,  X 
PRINT,  X , Y 
DO  10  I  =  1 ,  N 
Y  =  Y  +  DELTAY 
C  Use  equation  (1) 

X  =  X  +  DELTAY  *  F(X,Y) 
PRINT,  X , Y 
10  CONTINUE 
STOP 
END 


The  change  of  Y  in  discrete  units  1,...,N  expresses  uhe  rein¬ 
forcements  of  Y  in  terms  of,  say,  battalions.  Of  course 
;■  =  £  ( X ,  Y )  must  be  defined  in  a  FUNCTION  subprogram. 


For  a  fixed  value  of  Y^  we  can  have  an  error  which  increases 

2 

as  AY  increases  and  is  of  the  order  of  (AY)  . 

It  must  be  stated  here  that  there  is  a  bias  against  y  and 
o  for  this  kind  of  problems.  In  the  following  picture,  the 
solid  and  dotted  distribution  have  the  same  u  and  a.  However 
there  is  a  question  if  they  would  be  treated  the  same. 


In  addition,  another  question,  equally  reasonable,  is  how 
representative  are  monotonic  functions  in  expressing  the 
dynamics  of  the  critical  flank.  In  any  case  this  model  is 
very  tractable  analytically  and  there  are  a  lot  of  things 
that  could  be  done  in  this  vein. 

C.  THE  TARGET  DETECTION  MODEL 

Suppose  we  detected  a  group  of  enemy  targets  with  a  low 
resolution  radar  sensor.  The  display  shows  just  "blobs." 

The  question  is,  "Are  they  tanks  or  artillery,  or  some  mix¬ 
ture  of  both?"  We  decide  to  make  four  trials  with  another 
high  resolution  sensor  to  identify  each  one  of  the  four 
"blobs."  If  our  awareness  or  indifference  is  such  that  it  is 
equally  likely  that  they  are  tanks  or  artillery,  Figure  6.2 
shows  there  are  16  possible  outcomes  to  the  four  trials. 


Suppose  the  results  of  the  first  three  independent  trials 
were  "tank,  artillery,  tank."  To  the  question,  "What  is 
the  possibility  that  the  fourth  try  is  a  tank?",  the  answer 
is  1/2.  In  other  words,  by  considering  the  permutations  of 
trials  as  the  probability  space,  we  can't  learn  anything. 
Instead  of  this  from  our  knowledge  of  the  enemy's  organization 
we  can  express  our  indifference  by  equal  likelihood  in  terms 
of  distributions,  namely,  that  it  could  be  eitehr  100%  tanks, 
75%  tanks,  50%  tanks-  25%  tanks  or  0%  tanks,  and  make  them 
equal  in  probability  (Figure  6.3) .  Now  if  our  experience 
on  the  first  three  trials  was  "tank,  artillery,  tank"  then 
the  probability  of  the  fourth  trial  being  a  tank  is  3/5  =  .6. 
Ir.  other  words,  if  we  condition  the  probability  space  through 
the  use  of  distribution  of  ratios,  we  learn  more. 

D.  THE  "TWO  LOOKS"  MODEL 

The  previous  model  assumes  that  there  is  a  final  sensor 
which  makes  the  identification  of  tank  and  artillery  decisive 
and  correct.  This  is  not  usually  the  case.  It  is  often 
necessary  in  identifying  a  target  to  make  repeated  trials 
and  combine  ancillary  data  with  detection  data.  We  can  set  up 
a  decision  theory  .iodel  which  will  give  us  probabilistic 
limits  involved  in  looking  at  the  same  target  with  multiple 
sensors.  The  question  is,  "What  is  the  payoff  for  multiple 
sensors?",  or,  "If  we  make  repeated  trials  with  low  quality 
sensors,  do  we  in  fact  gain?"  Or,  "Shall  we  define  a  detec¬ 
tion  as  the  union  of  two  sensors  or  the  intersection  of  two 


The  analysis  would  be: 

Let 

p  =  "a  priori"  probability  that  a  target  is  in 
the  area 

=  Probability  to  detect  a  target  given  that  the 
target  is  present 

Pn  -  Probability  to  detect  a  target  given  that  the 
target  is  not  present. 

Then  the  probability  of  making  a  right  decision  is  given  by 
the  equation: 

PR  =  Pd.p  +  <l-Pn)U-p)  , 
and  the  probability  of  making  a  wrong  decision: 

PW  -  1  -  PR  -  (1-pd'-e  +  (1-P>'Pn 

If  is  the  loss  associated  with  a  Type  I  error 
(a  =  (1  -  P^)  *p)  and  is  the  loss  associated  with  a  Type  II 
error  ($  =  (1  -  p)  *Pn)  ,  the  expected  loss  for  a  wrong  decision 
is 

E  ( L)  =  a  •  +  8  • 

Let's  start  with  the  assumption  that  the  target  is  detected 
if  it  is  detected  with  either  sensor  A  or  sensor  B  or  both, 
that  is  (A  uB) .  The  improvement  "I"  can  be  defined  as  in 
Figure  6.5,  which  in  percentage  terms  becomes: 


I  [  (A  u  B)  , A] 


P(l-Pd(A) ) -Pd(B) •L1-(l-p)Pn(B) (l-Pn(A) -L2 
p(l-Pd(A) ) •L1+(l-p)Pn(A) -L2 

Let's  now  quantify  a  question  that  often  arises.  Suppose 

we  suspect  that  there  is  a  target  in  the  data  batch  from  the 

sensors.  The  sensor  being  used  has  a  fairly  low  probability 

of  catching  it.  How  much  do  we  gain  by  adding  a  second  sensor 

also  of  low  catching  probability?  Assuming  that  P^(A)  =  Pd(B) 

=  P,  and  that  P  (A)  =  P  (B)  =  P  ,  we  have: 
a  n  n  n 


I [ (A  u  B)  , A]  =  100  x 


P ( 1-Pd) ’ Pd*  Ll~ (1-P} ?n ( 1_Pn}  *  L2 

p(i~pd)  -Lj  +  a-p)  -pn-L2 


Assuming  also  that  Pn  =  .3,  L^  =  50,  L2  =  10,  p  €  [.1,19], 

and  Pd  e  [.1,19],  we  can  have  some  sample  curves  with  a 
simple  BASIC  program  (see  Appendix  A) .  Two  looks  are  not 
always  better  than  one.  We  could  require  that  both  trials 
A  and  B  (A  uB)  detect  a  target  before  a  target  is  said  to 
have  been  detected.  Such  a  procedure  would  decrease  the 
number  of  false  alarms  at  the  cost  of  missing  more  targets. 

If  detection  by  both  A  and  B  (A  n B)  is  required,  then 

Pd(AnB)  =  Pd(A)  *  Pd(B)  and 


P„  (A  n  B)  =  (A)  •  P  (B) 

n  n  n 

The  equation  for  the  expected  loss  from  a  wrong  decision 
is : 
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E  (L  (A  n  B)  ) 


p(l-Pd(A)Pd(B)  )  -1^  +  (l-p)Pn(A)Pn(B)  -L2 


« 


I 

I 


The  equation  of  improvement  is 


I  [  (A  n  B)  ,A]  =  (E  (L  (A)  -  E  (L  (A  n  B)  )  ) /E  (L  (A)  ) 


or 

p •  P  •,  ( A)  (1-P  (B)  )  •L,  +  {l-p)Pn  (A)  (1-P  (B)  )  -L- 

t  =  ion  x- _ 2 _ £l_ _ 1  n _ 5 _ £ 

p(L-Pd(A) ) •L1+(l-p)Pn(A) -L2 

Again  for  a  range  of  reasonable  values  of  p,  P^,  P^ ,  and 
1*2 »  we  can  have  some  sample  curves  that  show  that  in  any 
case  we  have  improvement  detecting  by  both  A  and  B  sensors. 
The  possibilities  of  using  three  or  four  trial  combinations 
using  the  intersection  concept  is  obvious. 

E.  THE  "WHAT  THE  ENEMY  IS  GOING  TO  DO"  MODEL 

If  whether  the  enemy  will  cross,  for  example,  a  river  is 
a  possibility  whether  or  not  it  is  true,  can  be  regarded  as 
hypotheses  and  the  data  from  the  intelligence  subsystem  can 
be  related  to  the  hypothesis.  In  a  simple  example,  we  can 
make  the  following  formalism: 

H  =  hypothesis  that  the  enemy  will  cross  the  river 
H'  =  hypothesis  that  the  enemy  will  not  cross  the  river 
D  =  data  from  the  intelligence  subsystem 
B  =  the  intelligence  background 


P  (H  |  B) 


probability  assigned  to  the  truth  of  H 
given  the  truth  of  B 


P (Hj  D,B)  =  probability  assigned  to  the  truth  of  H 
given  the  truth  of  D  and  B 

P(D|H,B)  =  probability  assigned  to  the  truth  of  D 
given  the  truth  of  H  and  B. 

Now  we  want  an  expression  for  P(H[D,B)  in  terms  of  H,  D,  B 
and  H'  because  we  want  to  accept,  reject,  or  modify  the 
hypothesis  in  light  of  the  data  from  the  field  under  differ¬ 
ent  states  of  knowledge.  This  expression  will  be  a  Bayes 
equation : 


P (H  |  D,  B) 


P (D|H,B) *P (H | B) 

P  (D  |  H ,  B)  *P  (D  |  B)  +  P(D|H',B)  *P(H' f"B) 


In  order  to  make  the  scenario  more  realistic,  let  us  assign 
the  following  concrete  meanings  of  the  above  formalism. 


P  ( H  |  B) 
P (H  *  |  B) 
P  (H  |  D, B) 
P (D | H ,B) 

P (D | H ' ,B) 


the  analyst’s  assignment  of  probability 
to  H  after  reviewing  the  background  B 

the  analyst's  assignment  of  probability 
to  H '  after  reviewing  the  background  B 

the  probability  of  H  after  data  from  the 
field 

the  probability  assigned  to  the  truth 
of  the  data  from  the  field,  assuming  the 
truth  of  H  and  B 

th  robability  assigned  to  the  truth  of 
dat  from  the  field  assuming  that  B  is 
true  and  H  is  false  or  H '  is  true. 


Now  we  want  to  know  whether  P(H|D,B)  goes  to  "0"  or  to  "1" 
or  stays  unchagned.  In  other  words,  we  want  P(HjD,B)  to  move 


to  "0"  or  to  "1". 


This  is  because,  if  I  have  a  hypothesis 


that  doesn't  move,  I  had  better  set  up  another  more  sensitive 
hypothesis.  To  make  this  point  of  view  clearer,  by  diving 
the  right  side  of  Bayes'  equation  through  by  the  numerator, 
we  have: 


P(H|D,B) 


1 


!  ,  P(D, 

H  '  ,  B)  *P  (H  ' 

Lb) 

x  pTd| 

H,B) * P  ( H 

B) 

or 


P(H|D,B) 


1  + 


P  (D  [  H  '  ,  B)  *  (l-P(HfB)  ) 
P  ( D I  H  ,  B)  *P  (H  I  B) 


Dividing  this  ratio  through  by  P(D|H',B)  we  have: 


1 

-  P  (H 

B) 

i  +  P<D 

H  ,  B)  *P  (H 

LBL 

P(D|H' ,B) 


That  is,  if  H  is  in  question,  then: 


P (H  |  D,  B) 


P  ( D 

H ,  B) 

P  (D 

H  '  ,  B) 

This  is  an  equation  of  low  resolving  power,  but  in  the  con¬ 
text  of  this  point  of  view,  two  issues  can  be  made  clearer: 

1.  Suppose  we  developed  the  hypothesis,  but  the  background 
was  such  that  P(H|B)  was  only  1/2.  The  question  is:  "How 
can  I  get  my  hypothesis  closer  to  certainty  ("1")  or  to 
uncertainty  ("0")?"  Say  that  p(H|D,B)  =  .8.  If  I  solve  the 


preceding  equation,  the  ratio  P ( D | H ,B) /P ( D | H ' , B)  must  be 
equal  to  4.  This  means  the  data  from  the  field  D  must  be 
4*B  truer  on  H  than  it  is  on  H',  in  light  of  the  intelligence 
background  B.  It  is  clear  from  this  that  a  prudent  indiffer¬ 
ent  hypothesis  must  collect  a  lot  of  critical  experimental 
data . 

2.  An  equivalent  but  perhaps  more  graphic  illustration  can 
be  set  up  this  way:  Suppose  P(H|B)  =  .8,  which  means  we  are 
pretty  sure  from  B  that  the  enemy  will  cross  the  river.  After 
we  get  the  data  from  the  field,  we  find  that  P(d|h,B)  =  .5, 
and  P(D|h',B)  =  .5,  which  might  mean  that  the  reports  can't 
be  preferentially  assigned  to  H  or  H',  considering  the  back¬ 
grounds.  Then 


p(HlD'B)  *  ,  ,  a-1-. si/. s  -  -8 

1  .5*. 8 

As  common  sense  suggests,  there  can  be  no  change  between 
P(H|B)  and  P(H|D,B)  when 

P(D|H,B)  =  P(D|H',B) 

but  we  can  also  argue  that  if  the  data  from  the  field  cannot 
change  a  prior  hypothesis,  there  is  in  effect  no  learning 


from  the  data. 


trials 


1st  2nd  3rd  4th 


1.  T  T  T  T 

2.  T  T  T  A 

3.  T  T  A  T 

4.  T  A  T  T 

3.  A  T  T  T  <*)  The  first  three  trials 

6.  T  T  A  A  were  "T-A-T" 

7.  TATA 

8.  T  A  A  T 

?.  A  T  T  A  The  Probability  that  the  4th 

10.  A  T  A  T  Try  will  be  " T "  is  1/2. 

11.  A  A  T  T 

12.  T  A  A  A  ••  He  Can't  Learn  A  Thing!! 

13.  A  T  A  A 

14.  A  A  T  A 

15.  A  A  A  T 

16.  A  A  A  A 

Figure  6. 2s  Unconditioned  Probability  Space. 
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VII.  EPILOG 


The  primary  purpose  of  this  study  was  to  produce  a  con¬ 
ceptual  framework  that  would  outline  from  a  system's  context 
how  a  SACS  (Staff  Assistant  Computer  System)  would  be  used 
to  support  staff  operations  within  the  LAF  (Large  Army  Forma¬ 
tion)  .  Another  purpose  was  to  present  some  mathematical  models 
for  assisting  the  intelligence  inference  beyond  the  experience 
and  the  perception  or  intuition  of  the  intelligence  analyst. 
Thus  this  study  had  two  main  objectives.  The  first  was  to 
develop  concepts  for  using  a  SACS  to  assist  in  accomplishing 
critical  functions,  duties,  and  tasks  that  must  be  performed 
within  those  command  and  control  elements  of  the  LAF  which 
will  be  affected  by  the  introduction  of  the  SACS.  The  study 
in  part  was  elaborated  to  provide  as  much  detail  as  possible 
(the  interface  with  a  LAF  wasn't  possible)  in  a  conceptual 
system  description.  This  foundation  is  needed  by  developers 
to  continue  the  analysis  to  the  next  level  of  a  detailed  study 
dealing  with  the  behavior  and  skills  associated  with  the 
design,  development,  and  use  of  the  several  sets  of  hardware 
and  software. 

Through  the  analytical  effort  involved  in  satisfying  the 
first  objective  of  the  study,  it  was  possible  to  identify 
critical  command  and  control  duties  related  to  the  military 
intelligence,  that  appeared  impossible  to  perform  effectively 


given  current  manual  procedures  and  projected  SACS  software 
capabilities.  Thus  identification  of  the  need  for  new  tools 
to  support  the  intelligence  inference  constituted  the  second 
major  thrust  of  this  study. 
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Artillery  Direction 

Stratopedo  Papagou 

Holargos,  Athens,  GREECE 

Maj.  (HA)  Panagiotis  Tsagaris  1 

SMC  #2697 

Naval  Postgraduate  School 
Monterey,  California  93943 

Maj.  (HA)  Athanasios  Kanellos  2 

SMC  #1517 

Naval  Postgraduate  School 
Monterey,  California  93943 
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